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Abstract 

/ 

The  Stanford  Network  Graphics  Project  has  the  goal  of  providing  high-quality  interactive  graphics  over  both 
local-area  and  long-haul  networks.  Specifically,  a  user  sitting  at  an  intelligent  workstation  should  have 
simultaneous  access  to  a  variety  of  graphical  and  non-graphical  applications  distributed  throughout  an 
internetwork.  Interaction  with  these  applications  must  be  responsive,  which  requires  that  much  of  the 
interaction  be  handled  by  the  workstation  itself.  To  do  so  the  workstation  must  deal  in  terms  of  high-level 
objects,  rather  than  graphical  output  primitives.  That  is,  it  must  provide  both  modeling  and  viewing  facilities, 
in  contrast  to  contemporary  graphics  systems,  litis  paper  describes  the  system  architecture  we  have  developed 
and  the  hardware  and  software  components  we  are  using  to  realize  this  architecture  in  the  Stanford  University 
Network  environment. 


This  research  was  supported  by  the  Defense  Advanced  Research  Projects  Agency  under  contract  MDA903- 
80-C-0102  I’his  paper  has  been  submitted  to  ACM  Transactions  on  Graphics.  An  earlier,  abridged  version 
was  submitted  to  Siggrapii  ’83,  ACM,  July  1983.  under  the  title  A  virtual  graphics  terminal  service. 
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—  1  — 
Introduction 

Computer  science  is  gradually  evolving  from  an  era  in  which  people  learned  to  adapt  to  machines  to  an  era 
in  which  machines  arc  made  to  adapt  to  people.  One  aspect  of  this  evolution  is  the  increasing  use  of  graphics. 
An  impediment  to  extensive  use  of  graphics  in  the  past  has  been  its  cost,  resulting  from  the  extensive 
processing,  storage,  and  communication  requirements,  and  the  need  for  expensive  displays  and  specialized 
hardware.  These  considerations  dominated  the  development  of  early  graphics  systems,  which  consisted  of 
graphics  devices  connected  directly  to  relatively  large-scale  computers,  cither  single-user  of  time-shared.  As 
these  devices  became  more  sophisticated,  the  load  on  timeshared  hosts,  in  particular,  became  insufferable. 

Fortunately,  the  development  of  microprocessors  led  to  satellite  graphics  systems  which  served  to  offload  a 
variable  amount  of  graphics  flinctions  on  to  another  machine  [23, 56].  The  more  powerful  the 
microprocessor,  the  more  ftinctions  tliat  can  be  offloaded,  until  the  satellite  system  takes  on  the  appearance  of 
the  host.  Typically,  however,  the  bulk  of  the  application  continues  to  run  on  the  host  computer. 

The  advent  of  networks,  local  networks  in  particular,  has  made  distributed  graphics  possible.  For  example, 
a  workstation  might  be  employed  as  a  remote  tenninal  or  a  satellite,  as  in  the  above  examples.  Alternatively,  a 
powerful  workstation  may  be  employed  to  provide  the  graphics  support  to  a  variety  of  backend  hosts  running 
various  applications.  Some  applications  might  run  local  to  the  workstation.  All  approaches  raise  the 
distributed  systems  issues  of  problem  partitioning,  concurrent  programming,  and  communications  protocols. 
Key  differences  from  satellite  systems  include  the  nature  of  the  interconnection  between  workstation 
(satellite)  and  host,  and  the  programmability  of  the  workstation.^ 

We  refer  to  these  types  of  systems  as  first,  second,  and  third  generation  systems.  Naturally,  there  are  a 
number  of  other  ways  to  categorize  graphics  oystems,  including; 

•  type  of  protocol  or  language: 

1.  mosaic 

2.  control  abstraction 

3.  data  abstraction 

•  type  of  graphical  representation  in  the  graphics  station: 

1.  frame  bufTcr  ot  storage  tube 

2.  simple  display  list 

3.  transformed,  segmented  display  file 

4.  structured  display  file 

5.  graphical  data  base  incorporating  the  application  model 

•  degree  of  user  interaction: 

1.  low.  as  in  videotex  prottKols 

2.  medium,  as  in  remote  terminal  applications 

3.  high,  as  in  real-time  animation 

•  bandwidth  of  the  host-workstation  interconnection: 

1.  low,  as  in  serial  lines  (for  videotex,  some  satellites,  etc.) 
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In  fact,  distributed  graphics  systems  might  be  regarded  as  programmable  satellites  in  the  sense  of  I'oley  [23], 
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2.  medium,  as  in  long-haul  networks 

3.  high,  as  in  local  networks 

A  number  of  these  factors  will  be  discussed  below.  All  of  the  factors  are  interrelated  and  none  of  them  are 
strictly  ordered  in  time.  Nevertheless,  going  from  first  to  last  in  each  category  corresponds  roughly  to  going 
from  terminal-based  to  distributed  graphics. 

The  Stanford  Network  Graphics  Project  is  concerned  with  third  generation  graphics,  that  is,  the  use  of 
graphics  over  both  local-area  and  long-haul  networks.  Specifically,  its  charter  is  to  develop  protocols  and 
software  that  allow  intelligent  workstations  to  be  separated  from  machines  running  applications  without 
incurring  inordinate  network  overhead  or  degrading  response.  In  addition,  the  workstation  must  be  capable 
of  supporting  multiple  applications  simultaneously. 

This  paper  describes  the  virtual  graphics  terminal  service  (Vgts)  developed  to  meet  these  goals.  The  major 
attributes  of  the  Vgts  are; 

•  Instead  of  describing  how  to  draw  a  picture,  the  application  describes  what  is  to  be  drawn;  the  user 
then  specifics  where  the  picture  should  be  displayed.  Thus,  the  Vgts  provides  modeling  as  well  as 
viewing  facilities,  in  contrast  to  most  existing  systems  [21, 25, 28], 

•  Objects  have  a  hierarchical  structure.  An  object  can  consist  of  primitives  or  calls  to  other  objects, 
which  can  in  turn  be  defined  in  terms  of  other  objects.  Hence,  the  Vgts  supports  structured 
display  files  rather  than  segmented  display  files  (401. 

•  fhe  Vgts  is  suitable  for  a  range  of  relatively  high-performance  devices.  There  is  a  standard 
interface,  called  the  virtual  graphics  terminal  protocol  (Vgi'P),  between  a  Vgts  and  its  clients. 
Nevertheless,  due  primarily  to  its  use  ofa  sti  icturcd  display  file,  the  Vgts  is  not  suitable  for  low- 
end  graphics  devices. 

•  Applications  can  be  distributed  over  multiple  machines.  They  can  run  on  the  same  workstation  as 
the  Vo  IS.  on  another  worksuition.  or  on  some  large  computation  server.  Since  communication  is 
at  a  high  level,  the  different  machines  may  have  vastly  different  architectures.  Moreover,  if  the 
application  is  written  in  a  suiuble  high-level  language,  the  same  code  can  be  used. 

•  A  single  user  can  access  several  different  applications  simultaneously. 

There  arc  several  similar  systems,  each  of  which  shares  one  or  more  of  these  attributes.  It  is  the  combination 
of  features  that  makes  the  Vo  I  S  unique  and  powerful. 

Setting  the  stage.  Section  '  ’  ribes  the  target  computing  environment.  Section  3  presents  the  network 
graphics  architecture  for  that  environment,  including  the  user's  model  of  the  system  and  the  role  of  the 
workstation.  Section  4  presents  the  application's  view  of  the  VGTS,  namely,  the  Vgtp.  Section  5  discusses  the 
transport  protocol  necessary  to  support  distributed  graphics.  Section  6  describes  an  implementation  of  the 
Vgi  S  and  Section  7  closes  viih  some  comparisrvns  to  other  systems  and  future  work. 
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—  2  — 
The  Environment 

Both  industrial  and  academic  research  laboratories  arc  investing  significant  resources  to  develop  systems 
composed  of  workstations  of  considerable  power  connected  to  each  other  via  high  speed  communications 
networks.  The  Stanford  University  Network  (Sun)  project  [7),  the  Spice  project  at  Camegic-Mcllon 
University  [4],  the  Eden  project  at  the  University  of  Washington  [341,  the  NU  [57]  and  l.isp[6]  machine 
projects  at  MI  T,  the  Jericho  project  at  BBN,  and  the  Cedar  project  at  Xerox  PARC  are  but  a  few  of  the  more 
prominent  projects  now  underway.^  It  seems  likely  that  within  the  next  five  years  such  systems  will  begin  to 
replace  large  timesharing  systems  as  the  workhorse  of  research  computing. 

Although  the  hardware  being  used  to  build  workstation-based  distributed  systems  ranges  from  the 
powerful  ECU  Dorado  [31]  to  MSI  TrU  processors  such  as  the  Perq  [55]  and  Jericho,  to  microprocessors  such 
as  the  Motorola  68000,  there  is  remarkable  uniformity  in  a  number  of  the  gross  hardware  characteristics  of  the 
systems.  All  the  projects  cited  (and  a  large  number  of  others)  will  provide: 

•  a  powerful  workstation  with: 

o  a  high-resolution  raster  display; 

o  a  general-purpose  1  MIPS  processor  plus  local  memory  (1  MByte  or  more); 
o  a  large  (>  20  bit)  virtual  address  space; 
o  a  graphics  input  device  such  as  a  mouse;  and,  optionally, 
o  a  disk 

that  (typically)  will  be  dedicated  to  a  single  user  at  a  time; 

•  a  fast  (>  1  MHz)  communications  network  that  will  link  the  workstations; 

•  a  number  of  server  prcKessors  providing  printing,  file  storage,  general  computation  support  on  a 
single  session^  basis,  and  other  services;  and 

•  access  to  timesharing  or  special  purpose  computers  and  to  long-haul  computer  networks. 

The  general  layout  and  interconnection  of  these  components  is  shown  in  Figure  2-1.  One  or  more  trunk 
nets  arc  connected  by  gateways  to  multiple  duster  nets.  A  trunk  net  consists  of  backend compuimg  resources 
such  as  laser  printers,  archival  file  storage,  and  large-scale  timesharing  systems.  A  cluster  consists  of  a 
collection  of  workstations  typically  associated  with  a  particular  administrative  entity.  Each  c'uster  may  have 
its  own  file  server  or  printer,  in  addition  to  those  provided  by  the  trunk  nets.  The  local  file  server,  for 
example,  would  act  as  a  file  cache  and  swapping  device. 


2.1 .  The  Stanford  University  Network 

Sun,  in  particular,  is  a  rapidly  evolving  computing  environment  consisting  of  standard  timesharing 
systems,  workstations,  and  dedicated  server  machines  (for  printing  and  file  .storage),  connected  by 
ethernet  [37]  (Figure  2-2).  Various  machines  are  alst)  connected  to  long-haul  networks  such  as  the  Arpanit. 


^Systems  such  as  the  Xerox  Star  [47]  and  the  Apollo  fTontain  12]  are  explicitly  excluded  from  this  list  because  they  arc  not  currently 
targeted  for  the  research  computing  environment. 
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fhe  processor  is  allocated  o  a  single  user  for  the  diiratioii  of  a  session. 


i 


m 


Arpanet 


W  =  Worl'statlon 

F  =  File  Server 

G  =  Gateway 

P  =  Printer 

A  =  Archival  File  Server 

T  =  Timesha red  Host 

Figure  2-1:  A  typical  workstation-based  distributed  system. 

The  environment  currently  provides  bulk  file  transfer,  page-level  file  access,  remote  terminal  connection 
( l  l  l  Nin  )  and  mail  delivery  between  hosts  [41], 

A  high  level  of  hardware  acquisition  is  planned  over  the  next  four  years  to  extend  the  functionality  into 
new  areas  such  as  higher-performance  graphics  and  professional  workstations  as  well  as  to  respond  to 
increasing  load  on  existing  facilities.  In  addition,  we  are  developing  a  wide  range  of  distributed  system 
services,  including  tlic  facilities  described  in  this  report. 

Sun  is  an  attractive  environment  in  which  to  experiment  with  network  graphics  for  several  reasons: 


im-  IINVIRONMI-NT 
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Figure  2-2;  The  Stanford  University  Network. 


•  Users;  Much  of  the  user  community  is  composed  of  computer  scientists  who  are  capable  of 
critiquing  the  facilities  we  provide  and  generally  willing  to  suffer  through  experimentation. 

•  Applications:  Applications  include  many  that  would  benefit  from  high-quality  graphics,  such  as 
VLSI  design  aids,  analysis  stations  for  VLSI  foundry  automation,  diKument  illustrators,  and 
image  analysis. 

•  Hardware;  The  necessary  hardware  exists  in  the  form  of  multiple  timesharing  systems,  dedicated 
server  machines,  and  high-performance  raster  graphics  workstations,  interconnected  by  a  variety 
of  networks. 

•  Software;  fherc  already  exists  much  of  the  software  required  to  make  SUN  a  productive 
environment  for  software  development,  document  preparation,  and  computer-aided  design.  We 
have  access  to  the  program  source  for  much  of  the  software  we  use  and  freedom  to  modify  and 
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extend  this  software  witliin  the  restriction  of  maintaining  functionality. 

In  the  following  sections  we  wilt  describe  briefly  the  salient  characteristics  of  our  user  community,  the 
principal  applications,  the  SUN  workstation,  and  the  operating  systems  and  networks  with  which  we  must 
cope. 


2.2.  Users 

The  present  SUN  user  community  consists  largely  of  research  computer  scientists  with  a  diverse  set  of 
needs.  These  users  can  be  categorized  as  "experts'*  who  find  it  relatively  easy  to  learn  to  use  new  computer 
systems  and  arc  highly  motivated  to  do  so.  Tlowcvcr,  this  does  not  mean  that  they  can  not  benefit  from  the 
use  of  well-designed  user  interfaces  that  reduce  the  amount  of  time  required  to  gel  things  done. 

The  remainder  of  the  user  community  consists  largely  of  secretarial  and  support  staff,  as  well  as  researchers 
in  other  departments,  who  use  our  timesharing  systems.  These  users  perform  typical  office  automation  tasks, 
such  as  text  processing.  The  Network  Graphics  Project  emphasizes  support  of  computer  science  research,  but 
recognizing  that  computer  scientists  often  perform  these  same  tasks  as  part  of  their  work,  we  believe  that 
support  for  office  automation  should  be  one  of  our  goals. 


2.3.  Applications 

As  in  any  large-scale  computing  environment,  there  is  a  wide  range  of  applications.  For  example,  a  vast 
amount  of  research  is  underway  at  Stanford  in  tlie  area  of  VLSI  design  and  fabrication.  Of  particular  concern 
to  Network  Graphics  are  Vl.Sl  design  aids(51.  Network  Graphics  and  the  ARPA-sponsored  VLSI  project 
seek  to  integrate  a  variety  of  analysis  and  synthesis  aids  distributed  across  the  local  network. 

The  VLSI  project  has  implemented  a  layout  editor,  Yai.i:,  that  runs  stand-alone  on  the  Sun  workstation, 
communicating  with  die  remote  host  only  for  purposes  of  retrieving  and  storing  chip  representations.  The 
Network  Graphics  Project  h.is  distributed  Y.\i  i-  between  a  Sun  workstation  and  a  VAX.  with  the  workstation 
providing  die  gniphical  Troiucnd  support  and  the  Vax  (or  equivalent  machine)  providing  the  analysis  tools. 
Details  are  described  in  subsequent  sections. 

A  new  VLSI  project  involves  pnx-ess  control  (.16).  Here,  workstations  will  be  used  to  monitor  the 
fabrication  facility,  .icting  as  sensors  and  analysis  suuions  The  analysis  stations,  in  particular,  will  be  required 
to  display  graphically  the  si.itc  of  the  f.icility  and  allow  an  operator  to  make  changes.  Network  Graphics  seeks 
to  provide  the  ncccs.sary  graphics  and  distributed  .system  support. 

A  third  area  of  interest  is  document  preparation.  This  includes  a  variety  of  text  and  figure  editors  of  the 
sort  prevalent  in  state-of-the-art  olTice  environments. 

I.astly.  wc  need  to  support  existing  non-graphical  applications  (such  as  text  editors  and  debuggers)  or  to 
extend  diem  w  ith  graphical  frontends.  With  die  increasing  use  of  graphics  workstations  and  die  development 
of  the  necessary  support  software,  wc  expect  the  use  of  graphics  to  become  the  nonn  rather  than  die 
exception.  That  is,  wc  believe  that  die  use  of  graphics  is  restricted  by  its  availability,  not  its  applicability. 


2.4.  Workstations 

In  1979,  Stanford  acquired  a  number  of  Altos  under  a  university  grant  by  Xerox  Corporation.  The  Alto  is  a 
16-bit,  microprogrammable  processor  with  a  606x808  raster  display  and  4  Mbyte  disk  (53].  It  was  one  of  the 
first  personal  computers  and  is  the  forerunner  of  the  Xerox  1)  machines,  including  the  Dorado  [31J  and  the 
Sutr  professional  workst.ition  147).  As  such,  the  Alto  and  its  attendant  software  has  served  as  a  guiding  light  in 
die  development  of  wdikst.uion  software  tliroughout  the  computing  community.  However,  having  been 
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designed  in  the  earlier  1970’s,  it  is  not  sufficiently  powerful  for  today’s  applications.  As  a  result,  in  197° 
Stanford  embarked  on  an  ambitious  project  to  develop  its  own  personal  computer.  The  result  was  the  Sun 
workstation. 


2.4.1 .  The  Sun  Workstation 

llic  basic  Sun  workstation  (7l  consists  of  the  following  components  (Figure  2-3): 


Multibus 


Figure  2-3:  Sun  workstation  hardware. 


•  proce.s.sor  board;  8  or  lO  MHz  68000/68010.  capable  of  executing  from  on-board  memory  without 
wait  states;  two-lcvcl  virtual  memory  management:  256  KBytes  of  on-board  main  memory;  high¬ 
speed  programmable  serial  channels;  16-bit  input  port  for  configuration  control;  five  16-bit 
timers,  one  of  which  can  be  configured  as  a  watch-dog  for  auto-reload  in  remote  applications 

•  graphics  system:  1024x1024  single-bit  pixel  frame  buffer,  of  which  800x1024  arc  normally  visible; 
video  refresh  logic;  lx  16-pixel  hardware  RasterOp\‘\Q\,  allowing  screen  fill  in  64  milliseconds  (32 
MBit/sec) 

•  network  interface:  .1  or  10  MBit  ethernet  interface  implementing  the  data  link  and  physical  layer 
functions;  4  KByte  receiver  I  li  o  allows  back-to-back  and  loopback  packets,  offering  a  latency  of  5 
milliseconds  for  2  KByte  packets;  using  zcro-acccss-time  port,  the  host  processor  interface 
supports  daUi  transfers  at  rates  up  to  4  Mbyte/sec 

•  display,  keyboard,  and  mouse 

The  entire  electronics  consists  of  260  chips  mounted  on  three  PC  boards  compatible  with  the  lF.HH-796  Bus 
(Intel  Multibus’*). 

As  a  result  of  the  modular  construction  of  the  hardware,  different  network  nodes  have  been  assembled 
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Multibus  is  a  tradcnwrl!  of  Intel  Corporation 
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using  the  processor  board,  the  ethemet  board,  and  other  boards  depending  on  the  application.  Examples 
include  terminal  concentrators  (Kthertips),  printer  servers,  file  servers,  and  gateways.  Additional  memory 
boards  may  be  used  to  allow  up  to  2  Mbytes  of  directly  addressable  physical  memory  and  an  additional  1 
Mbyte  of  Multibus  memory. 


2.4.2.  Iris  and  the  Geometry  Engine 

Rapid  response  requires  special-purpose  hardware  support  in  addition  to  the  general-purpose  processor 
and  graphics  controller  currently  available  for  the  Sun  workstation.  Color  graphics  arc  also  desirable, 
particularly  for  Vl.SI  design  aids.  Sumford  has  undertaken  the  development  of  two  complementary  systems, 
the  Iris  terminal  and  the  Geometry  Engine  [19]. 

The  Iris  (Interactive  Raster  Imaging  System)  terminal  is  a  variant  of  the  SUN  workstation  that  provides  a 
much  higher  performance  graphics  system.  IRIS  can  be  visualized  as  a  4-siage  Multibus-based  pipeline 
consisting  of; 

•  applications  processor:  the  standard  68000  board 

•  geometry  system;  itself  a  pipeline  of  10  to  12  custom  VLSI  Geometry  Engines,  which  together 
provide  a  sutek  of  4x4  floating  point  matrices,  matrix  multiplication  operations,  clipping  and 
scaling  operations,  a  hit-testing  mode,  and  curve  generation  capabilities;  capable  of  transforming 
3-1)  coordinates  at  a  rate  of  1  coordinate  every  15  microseconds 

•  frame  buffer  controller:  micimodcd  prcKcssor  based  on  the  AMD  2903  bit  slice  that  receives 
instructions  from  the  68000,  either  directly  by  bypassing  the  GH  or  indirectly  through  the  GE; 
responsible  for  supplying  bit  plane  controller  with  starting  values  for  the  Bresenham  coefficients 
used  for  vector  scan  conversion,  collecting  and  scan  converting  convex  polygons,  maintaining  a 
name  stack  Rir  hit-testing  purposes,  and  performing  clipping  and  hit-testing  on  fixed-  and 
variable-font  characters 

•  hit  plane  controller;  is  in  charge  of  vector  scan  conversion,  rectangle  filling,  character  painting, 
and  video  refresh 


2.5.  Operating  Systems  and  Networks 

I  hc  principal  pre-existing  operating  systems  with  which  need  to  communicate  arc  Unix^  and  rot>s-20.^ 
I'he  princip.il  network  architectures  are  Internet  (421  and  Pli’(9).  FUP  is  a  precursor  of  the  Xerox  Network 
Systems  Architecture  1201.  In  addition,  die  Network  Graphics  Project  is  developing  a  message-based 
distributed  operating  system  called  V  [171. 


^V'nix  IS  a  trademark  of  Ik'll  I  aboraiorics 
^  lops  .'ll  IS  a  trademark  of  Di^itai  I  quipmeiU  ( 'orporalion. 
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The  NetworkGraphics  Architecture 

The  software  structure  of  systems  composed  of  large  numbers  of  processors  connected  by  a  local  network  is 
still  being  hotly  debated.  This  section  develops  the  architecture  for  the  Network  Graphics  Project. 
Subsequent  sections  elaborate  on  specific  components. 


3.1.  The  User  Model 

In  the  previous  section  we  saw  that  tlie  user  requires  access  to  a  variety  of  applications,  distributed  literally 
throughout  the  world.  Wc  would  like  to  take  advantage  of  the  power  of  SUN-like  workstations  to  provide  a 
high-quality  user  interface  to  these  resources.  In  particular,  wc  would  like  to  make  graphics  an  integral  part  of 
the  user  interface  such  that  programs  exploiting  the  higher  bandwidth  of  pictorial  communication  arc  more 
the  norm  titan  the  exception.  This  section  presents  the  "ideal"  user  interface  that  we  arc  seeking  to  build. 

Sophisticated  user  interfaces  are  founded  on  three  fundamental  principles: 

1.  'Ihc  command  interaction  discipline  should  be  consistent  and  natural. 

2.  The  user  should  be  allowed  to  perform  multiple  tasks  simultaneously. 

3.  The  interface  to  application  programs  should  be  independent  of  particular  physical  devices. 

Ilic  first  principle  has  led  to  numerous  designs  for  command  languages.  ITie  second  has  led  to  a  great  deal  of 
work  in  window  systems.  The  tJiird  has  led  to  work  in  virtual  terminals  and  device-independent  graphics 
packages. 

In  view  of  these  principles,  wc  have  developed  a  system  architecture  that  allows  the  workstation  to  function 
as  the  frontend  to  all  avaihihle  resources.  When  the  user  boots  his  workstation  he  communicates  with  a  view 
manager,  which  allows  him  authenticate  himself  and  initiate  one  or  more  activities.  Hach  activity  may  be 
associated  w  ith  one  or  more  independent  virtual  graphics  terminals  (Vo  T).  l.-.ach  VGT  has  a  type  associated 
with  it  tliat  indicates,  for  ex.imple.  whether  lire  Vt;  I  w  ill  be  used  solely  for  text  or  for  graphics. 

A  Veil  mav  he  created  by  the  human  user  or  by  tlie  activity  itself.  When  the  user  wishes  to  initiate  a  new 
activity,  he  may  first  i  re.ite  a  new  Vgi,  with  an  .assiKiated  executive.  Ihe  executive  serves  as  a  command 
interpreter  from  which  the  desired  aciitity  may  then  be  initiated.  The  user  can  create  a  new  executive,  with 
V(,i.  at  any  time,  that  is,  asynchronous  to  any  existing  activities.  When  a  particular  activity  requires 
additional  virtual  gr.ipliics  terminals,  if  is  free  to  create  them.  Ihcsc  Vgts  will  be  deallocated  when  the 
activity  terminates,  whereas  Vtiiscreatcdby  the  user  may  only  be  deallocated  by  the  user. 

\'irtu.il  graphics  tcniiin.ils  are  mapped  to  the  screen  when  and  where  the  user  desires.^  A  particular  VGl 
may  be  m.ipped  to  sever.il  different  areas  of  the  screen  simultaneously.  1-iach  such  mapping  is  termed  a  viph'. 
Views  may  overlap.  When  an  activity  creates  a  new  VG  l  ,  a  default  view  is  used;  the  user  is  free  to  modify  that 
view  as  he  wishes. 

The  Network  Graphics  Project  is  not  concerned  with  solving  all  the  problems  of  command  interaction  and 
job  execution.  Howcvei,  simply  in  order  to  manipulate  the  screen  wc  must  provide  a  reasonable  command 
interface  -  for  creating,  destroying,  an'’  ranging  Vg  is;  zooming,  etc.  In  addition,  many  of  the  common 
command  interaction  techniques.  .u  .  menus  and  forms,  require  graphical  support,  which  the  Vgt 
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software  is  best  suited  to  provide.  Thus,  Network  Graphics  is  providing  the  tools  necessary  to  experiment 
with  a  variety  of  different  user  interfaces. 


3.2.  The  Role  of  the  Workstation 

The  user  model  suggests  a  number  of  requirements  with  respect  to  workstation  hardware  and  software: 

•  Workstations  supporting  graphics  must  become  predominant  so  the  graphics  hardware  capability 
is  widely  available. 

•  I'he  extensive  pr(x;essing  and  storage  capacity  required  for  responsive  interaction  must  be 
decoupled  from  the  unpredictable  response  behavior  of  standard  timesharing  systems, 

•  I'he  design  must  extend  to  now  hardware  and  the  increasing  demand  for  storage  and  processing 
power  in  a  cost-effective  fashion. 

The  requirements,  in  turn,  dictate  the  role  that  the  workstation  plays  in  the  distributed  system. 

To  date,  three  basic  approaches  stand  out: 

1.  nic  workstation  asf;«/f'///xe;/t^  lerniinal. 

The  workstation  serves  merely  to  offload  termmal  management  functions,  in  the  manner  of  fixed- 
funcliim  sateiliic  systems.  Workstations  have  frequently  been  employed  in  this  manner,  examples 
being  ADIS  [491,  A  T  [.3j.  and  die  Hell  Labs  Blit  terminal  [30). 

2.  The  workstation  as  personal  computer. 

I'he  workstation  is  viewed  as  a  single-user  computing  system  with  limited  requirements  for 
interaction  w  ith  external  processors.  Precisely  because  of  their  autonomy,  such  systems  are  free  to 
run  any  type  of  operating  sysicm  they  desire.  Aceess  to  remote  resources  is  typically  explicit, 
provided  by  a  collection  of  routines  designed  to  interface  die  workstation  to  backend  databases, 
file  servers,  priiueis,  and  the  like.  In  terms  of  graphics,  this  model  reverts  to  first  generation 
graphics,  w  here  the  .ipplication  .ind  .ill  the  graphics  facilities  are  asswiated  with  a  single  machine, 
l-xamples  include  movt  of  the  systems  built  around  die  Alto  and  its  successors,  die  Lisp  Machine, 

;ind  the  Perq. 

3.  i’he  workstation  as  eomponcni  of  a  distributed  multi-computer  system. 

A  number  of  unipriKc'ssor  systems  in  the  past  have  been  organised  around  die  principle  of  close 
interprocess  cooperation,  usually  through  a  form  of  message-passing.  The  emphasis  in  such 
systems  is  on  hie. iking  individu.il  tasks  into  a  number  of  priKesses  that  communicate  to  solve  a 
problem.  In  .tddition,  the  functions  commonly  assiKiated  with  an  operating  system  can  be 
provided  by  processes.  In  sever.il  cases,  these  systems  have  been  transparently  extended  to  a 
network  environment  in  which  the  workstation  provides  a  set  of  functions  as  defined  by  the 
processes  running  on  it.  Ihus.  the  workstation  may  play  any  role  --  intelligent  tcmiinal, 
comptitation  server,  file  server,  etc.  -  with  equanimity.  RiG  [32],  Spice  [4],  and  V  are  examples  of 
this  appro.ich. 

The  choice  of  role  for  the  workstation  primarily  depends  on  die  available  hardware  and  the  .application 
environment.  In  terms  of  hiirdware.  "small"  workstations  are  best  suited  .as  intelligent  terminals,  whereas 
person. il  computing  retiuires  re.isoiuibly  "targe"  workstations.  In  particultir,  personal  computers  typically 
have  their  own  disks,  "(.'omponent"  workst.itions  f.ili  somewhere  in  between,  requiring  enough  hardware 
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support  (c.g.  memory)  for  a  reasonably  sophisticated  distributed  kernel,  but  not  as  much  as  a  stand-alone 
computing  system  would  require.  In  particular,  they  do  not  require  a  local  disk,  which  reduces  the  cost  per 
workstation  and  avoids  the  power,  noise,  heat,  and  space  limiuitions  imposed  by  the  user’s  office 
environment. 

In  terms  of  application  environment,  intelligent  terminals  and  personal  computers  represent  a  rather 
constrained  view  of  workstations.  In  die  first  case,  the  power  of  most  existing  workstations  is  wasted  if  they 
can  only  provide  tcmiinal  management  functions.  In  the  second,  the  workstations  arc  isolated  from  the  rest 
of  the  world,  under  the  false  assumption  diat  they  can  provide  all  the  functions  necessary. 

For  example,  local-nct-bascd  systems  have  been  built  in  which  die  workstation  maintains  little  or  no 
infonnation  as  to  what  is  being  displayed.  I'hat  is.  the  workstation  docs  not  support  a  display  file.  Rather,  the 
remote  application  maintains  all  the  data  structures  relating  its  output  to  areas  on  the  display  and  issues  the 
equivalent  of  line-drawing  or  "remote  HitBIt"  commands  to  the  terminal.  This  leads  to  frequent  and 
potentially  data-intensive  communication  between  the  host  running  the  application  and  the  workstation.  This 
approach  has  been  successful  due  to  the  speed  of  the  communication  media  and  the  relative  simplicity  of  the 
applications. 

However,  as  the  use  of  graphics  becomes  pervasive,  we  must  address  more  seriously  the  issues  involved  in 
transmitting  graphical  infoiin.ition.  In  particular,  in  a  long-haul  environment,  the  level  of  interaction  just 
described  is  proliibitive.  Because  transmission  bandwidth  is  expensive  and  a  typical  raster  screen  may  need 
125  K  Bites  to  represent  a  complete  image,  clever  protocols  arc  needed  to  transmit  the  essence  of  the 
information  without  incuiiuig  excessive  costs.  Hie  worksuition  software  should  be  capable  of  handling 
higher-level  objects  than  lines  and  biim.ips  and,  in  addition,  should  support  local  editing.  By  so  doing,  the 
frequency  of  the  comnuinic.ition  atid  the  amount  of  d.ita  transferred  on  each  communication  arc  substantially 
reduced.  Workstations  now  being  built  ,ire  powerful  enough  to  provide  this  functionality  via  structured 
display  files. 

rurning  to  the  person, il  computer  appro.teh.  many  tipplications  require  prtKcssing  and  storage  capacity  that 
far  exceed  wh.it  is  economic  to  dedicate  to  a  single  user's  ••fficc  or  what  is  acceptable  in  the  user's 
environment.  Thus,  some  portion  of  the  .ipplication  must  reside  on  another  host.  If  workstation  software 
supports  tr.iiisparent  vlistiihuted  oper.iiion.  it  is  possilile  to  configure  the  system  at  run-time  to  use  ciilicr  local 
or  remote  resources.  1  h.it  is.  the  p.irtiiioning  boundaries  may  be  changed  without  having  to  rewrite 
application  softw.ire 

(Inis,  we  h.ive  chosen  to  ire.it  tlie  worksi.iiion  .is  a  ciiiiifuiiiciii  of  a  distributed,  multi-computer  system.  We 
do  not  waste  its  powei  by  ire.ning  it  solely  as  a  dumb  terminal  nor  do  we  isolate  it  from  the  rest  of  the  world 
by  tre.itmg  it  solely  as  ,i  personal  computer.  Rather,  we  assume  that  the  workstation  may  play  any  role 
deemed  .ippropri.iie  by  the  user,  the  hardware,  and  tlic  applications  at  hand. 


3.3.  The  Architecture 

I'he  resulting  softw.ire  .irchitectiire  fits  the  classic  ohjcct  or  server  model  [29,  58);  The  world  consist  of  a 
collection  of  resai/rees  .iccessible  by  elieiils^  and  m.in.iged  by  servers.  A  server  defines  the  abstract 
represent. ition  of  its  resource(s)  .nul  the  operations  on  this  represent.ition.  A  resource  m.iy  only  be  accessed 
or  m.inipiil.ited  through  its  server.  Because  serveis  are  constructed  with  well-defined  interfaces,  the 
implementation  det.iils  of  a  resource  .ire  of  eoncern  only  to  its  server.  Note  that  a  server  frequently  acts  as  a 
client  when  it  .icccsses  resources  maii.iged  by  other  servers.  Thus,  elieni  .ind  senrA arc  merely  roles  played  by 
a  prix-css  or  module. 


8 


Wc  will  use  ihc  Icnii  vlivri  id  refer  lo  ;i  luiiicin  user  or  program  iei|uesiiiig  .irress  In  a  lesoiirre 


exclusively  lo  humans 


Wc  will  use  Ihc  icnn  irvcr  lo  refer 


Trsssmmmam 


12 


THIRDGIM  RAl  lON  GRAPHICS  POR  DISTRIHL  H'D SYSl PMS 


Clicins  anil  servers  may  be  disiribuied  throughout  the  (iiner)nctwork.  By  default  access  to  resources  is 
network  transparent',  a  client  may  access  a  remote  resource  with  the  same  semantics  as  it  accesses  a  local 
resource.  I'he  result  is  an  environment  in  which  clients  may  communicate  with  servers  without  regard  for  the 
topology  of  the  distributed  system  as  a  whole.  However,  we  do  not  intend  that  a  client  cannot  determine  or 
inHucnce  the  location  of  a  particular  resource,  rather  that  a  transparent  mechanism  is  available.  Moreover,  we 
must  allow  for  clients  and  .servers  that  were  not  written  with  network-transparent  access  in  mind. 

From  the  point  of  view  of  user  interaction,  tlic  principal  resource  is  the  workstation,  the  server  is  the  VOTS, 
and  clients  consists  of  the  user  and  application  programs.  Figure  3-1  presents  the  interrelationships  among 
these  components. 


Figure  .3-1;  High-level  network  graphics  architecture. 

Follow  ing  the  traditional  virtual  terminal  model,  applications  communicate  with  the  Vgts  via  the  tcnninal- 
iiulepenilent  virtual  firaphles  terniinal  protoeol  (Vgip),  and  witli  host  software  in  whatever  way  necessary. 
I  he  Vg  i  s  eoinnninieates  w  ith  the  hanlw.irc  via  the  terminal-dependent  real  terminal  protocol  (R  \v).  Thus, 
the  Vgis  provides  a  protocol  translation  service  between  Vg'ip  and  Rl'P.  Alternatively,  the  Vgip  defines  the 
interface  or  vcinaniics  at'  lYic  Vtt  r.S, 
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The  Virtual  Graphics  Terminal  Protocol 

An  interactive  program  generally  consists  of  a  froniend  that  converses  with  the  user  and  a  backend  that  docs 
the  real  processing.  A  frontend  invariably  fits  tlic  editor  paradigm  because  it  must  allow  the  user  to  enter,  edit 
and  display  as  part  of  his  interaction.  I'hus.  the  ideal  Vc  is  would  provide  this  common  editing  portion  and 
avoid  die  duplication  and  inconsistent  interfaces  that  currently  abound  between  applications.  We  argue  that 
any  limiuitions  and  structuring  constraints  that  the  Vgts  may  impose  on  different  program/user  interfaces 
arc  justified  in  return  for  a  more  uniform  user  interface  overall. 

The  hard  problem  is  defining  a  good  interface  (Vgtp)  to  the  Vgts.  'ITiis  is  hard  because  there  arc  many 
applications  with  different  requirements.  On  the  other  hand,  the  VGTS  must  be  reasonably  efficient,  which 
would  not  be  possible  if  it  tries  U)  do  too  much 


4.1 .  Interactive  Graphics 

An  interactive  program  generally  operates  in  a  response  cycle.  A  user  action  is  signaled  by  an  input  device 
(such  as  a  keyboard  or  mouse)  I  bis  signal  is  communicated  to  the  application  program  which  then  processes 
the  user  action  and  generates  <in  application  reaction  dial  is  indicated  on  an  output  device  (typically  the 
display).  I'hc  response  time  is  the  time  from  user  action  until  the  reaction  is  .  '^olayed. 

This  full-cycle  response  cycle  must  in  the  network  graphics  setting  go  through  the  Vgts,  die  local  agent,  the 
workstation  network  software,  over  the  network,  through  the  application  processor  network  software,  cause 
the  application  to  be  scheduled,  and  after  the  application  has  generated  die  response,  return  across  the  same 
route.  In  our  concern  for  higli-quality  interactive  response,  there  is  a  need  to  choose  the  VGTP  to  allow  the 
response  cycle  to  be  short-circuited  for  some  user  actions,  as  illustrated  in  Figure  4-1. 


VGTS  Interface 


Interactive  Response  Cycle 


f  igure  4-1:  Short-circuiting  of  the  response  cycle. 

Short-circuiting  is  possible  at  .t  number  of  different  levels,  including: 

•  mouse-controlled  cursor:  1  he  updating  of  die  cursor  position  is  performed  by  the  VGTS  in 
response  to  user  motion  of  the  mouse  (or  similar  pointing  device). 


•  screen  management  functions:  Ibis  is  ncccs,sary  to  allow  distributed  applications  to  run 
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concurrently  without  interference. 

•  hit  detection;  Here,  applications  arc  informed  when  a  significant  event  occurs,  such  as  selection  of 
ail  object;  they  do  not  keep  track  of  tlic  cursor  position. 

•  graphics  editing;  The  VGis  supports  editing  of  the  graphical  objects  so  only  some  high-level 
indication  of  tlie  editing  changes  needs  to  be  communicated  to  the  application. 

Higher-level  short-circuiting  provides; 

1.  better  response  for  operations  that  can  be  short-circuited, 

2.  better  utilization  of  worksuttion  resources,  and 

3.  reduced  programming  and  processing  demands  for  applications. 

Typically,  those  operations  that  cannot  be  short-circuited  are  more  expensive  to  begin  with  and,  hence,  have 
greater  overhead  in  die  user's  mind.  Hie  longer  response  is  acceptable  in  diat  it  meets  the  user’s  expectations. 

However,  to  provide  high-level  short-circuiting,  the  Vo  rs  needs  to  be  provided  with  high-level  information 
about  input  and  display  semantics.  1  hat  is.  the  VoiT  must  allow  the  applieation  to  communicate  the  model 
diat  it  is  representing  pictoiially,  not  just  the  image  of  diat  model.  For  instance,  a  circuit  drawing  program 
may  need  to  communicate  that  a  Nou  gate  is  logically  a  single  unit,  not  a  collection  of  lines  and  arcs,  so  the 
Vgis  can  support  editing  die  circuit  without  communicating  with  the  application  itself.  If  die  NoR  gate  is 
communicated  to  the  \'Gis  as  a  sequence  of  low-level  graphics  operations,  the  Vgts  cannot  know  the 
smicture  tif  die  underlying  object. 

Ihis  requirement  suggests  in  turn  diat  arbitrary  amounts  of  processing  and  storage  capacity  can  be  used 
effectively.  This  may  be  supported  by  simply  considering  the  issue  of  incremental  versus  complete  image 
redrawing.  Some  graphical  representations  and  proUKols  provide  structuring  on  the  image  representation  to 
facilitate  incremental  update  of  the  display  when  some  aspect  of  the  image  is  changed.  We  have  instead  used 
the  structure  to  encode  apphcation-meaningtul  information  and  semantics.  This  may  be  of  no  help  or  in  fact 
contrary  to  incrcmciii.il  update  speed.  In  that  vein,  it  would  be  simplest  from  the  point  of  view  of  designing  a 
Veils  to  simply  redraw  the  image  from  its  figure  representation  after  each  update  (as  currently  done  in  the 
Iris  terminal). 

For  this  discussion,  we  see  tliat  key  issues  in  the  design  of  a  Vgtp  are; 

•  support  for  inicraciioii  .indgood  response;  and 

•  function  p;irtitioning. 

In  general,  our  major  ch.illengc  is  to  design  a  means  of  high-level  communication  instead  of  relatively  low- 
level  comniunic.ition  tli.ii  has  been  previously  used.  There  is  a  strong  analogy  to  be  found  here  with  tlie 
development  of  high-level  piogr.imming  languages. 


4.2.  The  Programming  Language  -  Protocol  Analogy 

I.aiigti.iges  arc  relaicil  to  proiociils  in  that  an  inieniclivc  hm^unge  is  a  prottKol  in  computing  terminology. 
The  history  of  programming  l.mguagcs  might  be  broadly  summarized  as  a  struggle  to  develop  high-level 
languages  for  describing  programs.  The  major  problems  have  been; 

1.  efficiency  versus  generality;  and 

2.  stnicture  versus  expressibility. 

We  perceive  a  gradu.il  convergence  in  programming  languages  from  prnhicm-oricnicd  languages  to  a  few 
widely  used  languages  plus  .i  wider  acceptance  of  disciplines  in  structuring  programs  in  particular  forms  Uiat 
arc  explicitly  supported  by  the  l.mgu.igcs.  In  this  sense,  modern  programming  languages  do  not  support 
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doing  all  things  in  all  possible  fashions,  but  doing  reasonable  things  in  a  reasonable  fashion. 

In  examining  the  structure  of  high-level  programming  languages,  there  appears  to  be  three  basic  levels  of 
languages. 


1.  machine  language 

2.  control  abstraction 

3.  data  abstraction 


Machine  language  deals  with  the  representation  understood  by  the  processor.  Control  abstraction  languages 
have  primarily  dealt  with  pro\iding  control  constructs  such  as  if...thcn...clsc.  while  loops  and  procedures. 
BCPl ,  For  I  RAN  and  numerous  other  languages  arc  at  this  level.  Data  abstraction  languages  appeared  later 
with  the  recognition  tliat  daut  structuring  was  die  central  usk  in  designing  larger  programs.  It  is  no  accident 
that  one  of  die  major  features  of  Pascal  over  Algoi.  is  Pascal's  data  structuring  facilities. 

The  categorization  of  programming  languages  provides  a  basis  for  classifying  graphics  protocols. 
Specifically,  we  can  identify  three  classes  of  protocols  that  roughly  correspond  to  the  three  levels  of 
programming  languages. 

1.  protocols 

2.  control  abstraction  protocols 

3.  data  abstraction  protocols 

These  protocols  differ  primarily  in  the  graphical  reprcsentalion  that  diey  employ  to  communicate.^  Drawing 
the  analogy  with  programming  languages,  we  claim  diat  success  with  high-level  graphics  proUKols  is 
contingent  on  finding  and  accepting  stnicturc  within  our  graphical  communication.  Judging  by  the 
experience  with  programming  languages,  this  may  well  be  a  long,  painful  process. 


4,2.1 .  Mosaic  Protocols 

Mosaic  protocols  arc  characterized  as  using  a  graphical  representation  as  a  mosaic  of  fixed  size,  shape  and 
color  primitives  combined  into  a  picture.  This  representation  may  be  stored  directly  on  a  storage  tube,  or  in  a 
frame  buffer  or  intermediary  bimiap  for  raster  displays,  l-ixamplcs  include  the  Prcstcl  videotex  protocol  (10], 
facsimile,  and  remote  biim.ip  protocols.  Prcstel  is  die  best  example  in  that  it  produces  pictures  using  shapes 
much  like  the  pieces  of  tile  found  in  mosaics.  Bitmap-level  protwols  arc  simpler  but  use  essentially  one  shape 
and  size  of  tile  vsiili  only  the  color  being  variable. 

There  is  a  tradeoff  between  quality  and  quantity  in  mosaic  resolution.  The  cost  of  communicating  the 
mosaic  pieces  may  be  reduced  thixmgh  the  use  of  compression  techniques,  such  run-length  encoding.  Mosaic 
proUKols  have  the  advantage  of  requiring  only  a  simple  display  priKcssor  and  being  tolerant  of  lost  data  due 
to  the  redundancy  in  the  image. 

However,  mosaic  protocols  incur  costs  in  communication  and  storage.  More  importantly  for  us,  die 
structure  of  the  picture  is  not  explicit.  This  limits  die  short  circuiting  of  interaction  due  to  the  low  level  of 
rcprcsetitation,  e.g.  cursor  and  \  iruial  frame  buffer  management.  A  further  disadvantage  (and  similarity  to 
machine  language)  is  device-dependence. 


Note  ijiat  som'mI  powerful  rum  inler.irliM'  prapliics  rcprisenl.itioiw  have  been  designed  H  X  tlVI  and  Xerox  Press,  for  example, 
are  slruclured  lo  facllilalc  sei|uenli.il  gener.iiion.  rapid  page  layout  and  prinling.  and  compact  representation 
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4.2.2.  Control  Abstraction  Protocols 

In  a  control  abstraction  protcKol.  tltc  graphical  representation  is  a  sequence  of  drawing  operations,  such  as 
DrawLine,  DmwCircle,  etc.  This  is  roughly  analogous  to  the  control  abstraction  programming  languages  in 
that  basic  control  functions  have  been  abstracted.  I'he  primitives  are  stored  in  some  form  of  display  list  or 
display  fdc.  Primitive  staicturing  facilities  may  be  provided  in  the  form  of  segments,  in  which  case  a 
segmented  display  file  is  employed.  Kxamplcs  include  most  current  graphics  protocols,  including  the  Core 
System  [25],  Gks  [28],  and  the  I'clidon  videotex  protocol  [12,  13).  A  survey  of  other  popular  protocols  may  be 
found  in  [21]. 

Control  abstraction  protocols  have  the  advantage  of  lower  communication  and  storage  cost.  In  this  sense, 
transmitting  and  storing,  for  instance,  an  image  of  a  circle  as  a  single  DmwCircle  operation  with  its  radius  and 
center  coordinates  can  be  viewed  as  a  data  compression  technique  over  storing  tlic  mosaic  pieces  constituting 
the  circle.  Control  abstraction  prottKols  have  the  further  advantage  of  offloading  part  of  the  graphics 
calculations  from  die  application,  c.g.  mapping  from  DmwCircle  to  die  raster  operations.  They  also  support  a 
higher  degree  of  dcvicc-indcpcndencc  since  images  can  be  produced  according  to  the  technology  and 
resolution  of  the  display  from  each  specified  operation. 

However,  die  potential  for  interaction  short-circuiting  remains  limited  due  to  the  primitive  structuring 
facilities.  For  example,  the  draw  operations  to  produce  an  image  of  a  bicycle  need  not  communicate  anything 
of  the  stmeture  of  die  bicycle.  I'hus.  the  user  can  not  edit  die  bicycle  structure  without  communicating  with 
die  (remote)  application. 


4.2.3.  Data  Abstraction  Protocols 

Graphical  representation  in  data  absti.\ction  proUKols  is  in  terms  of  figures,  stmeture  imposed  on  figures 
and  dieir  aliributcs.  Flerc.  a  Jigare  is  die  graphical  equivalent  to  objects  in  data  abstraction  programming 
languages.  Its  key  characteristics  arc; 

•  Figures  arc  semantically  meaningful  objects  to  the  application. 

•  I'he  structure  of  figures  is  explicitly  represented. 

The  figure  reprcsentatiim  encodes  some  piece  of  the  application  model,  not  just  the  pictorial  image.  This 
provides  the  stmeture  and  ''emantics  required  for  high-level  interaction  short-circuiting.  Thus,  we  sec  the 
need  to  explore  diis  class  of  protocols  further,  analogous  to  die  on-going  work  in  data  abstraction  languages. 

Ironically,  a  number  of  early  graphics  systems  took  this  approach  to  its  extreme  by  merging  die  application 
model  and  the  display  file  into  a  single  graphical  data  /w.vcflS.  45.  51).  I  his  approach  fell  in  to  disfavor 
largely  because  it  imposed  a  fixed  graphical  representation  for  all  applications.  In  light  of  distributed 
graphics,  it  is  also  impractical  to  support  a  single  daui  structure  spanning  multiple  machines. 

A  number  of  subsequent  systems  developed  the  notion  of  a  structured  display  file  that  encodes  the 
hierarchical  structure  of  figures,  but  leaves  most  of  die  application-specific  information  in  a  separate 
application  model  [8.  50,  54).  I  he  structured  disjilay  file  is  partially  redundant,  but  provides  a  reasonable 
amount  of  structure  for  high-level  short-circuiting.  We  draw  much  of  our  inspiration  from  Sproull  and 
Thomas’s  siniciured  formal  protocol,  outlined  in  1')’74  but  never  implemented  |50|.  That  protrKol,  in  turn,  was 
inspired  in  part  by  a  system  built  at  MIT's  Lincoln  Laboratory  as  part  of  the  Lt:Al>  language 
development  [22, 40j. 
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4.3.  Partitioning  of  Function 

One  of  the  most  important  issues  to  address  is  the  partitioning  of  function  between  the  various  software 
and  hardware  components.  1  his  issue  arises  when  determining  what  functionality  to  give  to  the  Ve  rs,  where 
to  place  die  graphical  database(s),  and  when  and  how  to  distribute  an  application.  It  would  be  easy  to 
overload  eidier  die  Vgis  or  the  application,  the  workstation  or  the  host. 

Although  application-  and  dcvicc-indcpcndcncc  is  a  laudable  goal,  it  can  lead  to  a  VGTS  that  suppe  ts  too 
niiicli  function  for  some  applications  and  too  little  function  for  others.  Both  situations  lead  to  excessive 
overhead:  the  first  because  the  V'Gts  is  doing  do  much;  the  second  because  the  application  must  go  to  extra 
lengths  to  "subvert"  die  V'GTS.  l-'or  example,  if  the  Vgts  were  "optimized"  for  die  basic  Sun  worksttition,  it 
would  include  a  variety  of  routines  for  clipping,  scaling  and  the  like.  However,  in  the  Iris  terminal  these 
functions  arc  provided  in  hardware  by  the  Geometry  f-ingine.  Thus,  die  Vgts  itself  must  be  structured  as  a 
collection  of  building  blocks.  Moreover,  the  IRIS  provides  considerably  more  functions  than  the  SuN 
workstation,  requiring  additions  to  the  Vgi  r.  Careful  thought  must  be  given  to  the  design  of  the  Vg'I  p  such 
diat  it  allows  for  terminal  negotiation  of  the  sort  commonly  found  in  traditional  network  virtual  terminal 
protocols. 

Replication  of  data  is  another  problem.  I’lic  application,  the  Vg  i  s.  and  the  frame  buffer  each  maintain 
representations  of  the  data,  l  or  the  most  part,  the  representations  arc  at  different  levels  (objects  vs,  bit.s,  for 
instance),  but  each  level  adds  overhead.  If  the  dat;i  typically  is  changed  in  response  to  user  interaction,  dicn 
the  Vg  is  should  have  fast  access  to  the  graphical  database;  diat  is,  the  VGTS  shot-id  maintain  the  database. 
On  die  other  hand,  if  the  application  drives  most  of  the  changes,  it  should  maintain  the  database. 

Oistribution  raises  additional  problems.  In  all  cases  we  would  like  to  limit  both  the  frequency  of 
communiciition  and  the  amount  of  data  transmitted  at  any  one  lime.  In  some  cases  this  w  ill  require  caching 
mech.uiisms  on  the  St  \  workstation  and  necessitate  additional  protocols  to  keep  die  workstation  cache 
s>nchroni/ed  with  the  remote  datalvase  (see  Section  5). 

A  more  basic  question  is  when  to  distribute  the  application  in  the  first  place.  Language,  storage,  or  speed 
requirements  ma>  necessitate  that  the  application  run  on  another  host.  In  addition,  using  a  w'orkstation 
wiihout  a  local  disk  niav  imply  a  substantial  amount  of  file  traffic  for  swapping.  Reducing  the  load  on  the 
workst.ition  limits  this  activity. 


4.4.  A  Virtual  Graphics  Terminal  Protocol 

We  now  describe  .i  first  attempt  at  <i  Vgit  that  addresses  die  issues  Just  discussed.  The  V'g  iT  manipulates 
two  basic  types  (i|  structures;  siiutiunJ  Jisphn  files  (Sl)i  )  and  viriudl  graphics  icnninals.  livery  graphical 
object  is  ilefmcil  within  .i  specific  Sdi  ;  thus,  an  SgT'  represents  an  object  tlrfiiiiiini  space.  In  order  to  view  an 
object,  it  IS  ncccss.uv .  first,  to  associate  its  Sl7l  with  a  Vg  I  and.  second,  to  specify  a  mapping  of  the  Vtj  r  to  die 
user's  screen. 


4.4.1 .  Object  Management 

An  Sdi  consists  of  a  collection  of  iinns.  I'he  items  can  be  grouped  into  symbols,  w  hich  can  in  turn  contain 
inst.inccs  of  oiher  symbols,  to  any  desired  depth.  Items  arc  named  by  identifiers  chosen  by  the  application 
and  .lie  typed.  Current  item  types  include: 

•  point 

•  line 

•  fillcil  rect.ingle 

•  text 

•  symbol  definition 
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•  symbol  call 

A  cliciu  can  create  and  delete  structured  display  files,  symbols,  or  items.  It  may  edit  symbols,  and  obtain 
and/or  change  tlic  properties  of  an  item  (including  type  and  exieni  [24]).  ITie  following  functions  are 
provided: 

CreateSDFO  ~  >sdf 

Creates  a  stnicturcd  display  file,  and  returns  it  in  sJf.  This  must  be  done  before  any  symbols  are 
defined. 

DeleteSDF(sJJ) 

Returns  all  the  items  defined  in  the  given  sdf  to  free  storage. 

DefineSymbol(s(l/,  item,  name) 

Kilter  a  symbol  into  the  symbol  table,  and  open  it  for  editing.  The  sdf  \s  returned  from  a  previous 
CreateSDF  call,  iicm  is  an  application-specific  integer  identifier  for  the  symbol  and  name  is  an 
optional  string  name. 

EndSymhol  (sJf,  hem.  vgi) 

Close  symbol  iiem  in  stif  so  no  more  insertions  can  be  done,  and  cause  the  vgt  to  be  redrawn  to 
reflect  the  new  .w//.'  Called  at  the  end  of  a  list  of  items  defining  a  symbol,  started  with 
CreateSymbol  or  FditSynibol. 

EditSymbol  (sdf,  hem) 

Open  existing  symbol  item  in  sdf  (ox  modification.  This  has  the  effect  of  calling  DefineSymbol  and 
inserting  all  the  already  existing  entries  to  the  definitions  list.  The  editing  process  is  ended  in  the 
same  way  as  die  initial  definition  prtKCSs  •  a  call  to  EndSymbol. 

DeleteSymbol  (sdf  hem) 

Delete  the  definition  of  sy  mbol  hem  from  sdf  Any  dangling  instances  of  this  symbol,  created  by 
CallSymbol.  will  remain,  but  will  contain  nothing. 

CallSymhol  ( sdf  hem,  affset,  eallcdSymbol) 

Add  an  instance  of  e<dledSymb()l  to  the  currently  open  symbol  in  the  sdf  The  instance  is  given  die 
name  hem.  I  he  called  symbol's  origin  will  be  placed  at  ujfsei  in  die  calling  symbol’s  coordinate 
space;  it  is  not  cli|iped  or  transfonned  in  any  other  way.  This  is  equivalent  to  a  move  call  unh  in 
Spimill  and  Thomas's  structured  fonnat  protocol. 

Addltem(sdf.  item,  e  xieni.  type,  type  Data) 

,^dd  an  item  to  the  currently  open  symbol  in  die  sdf  giving  it  the  name  hem.  exieni  specifics  the 
bounding  box  of  the  item  in  its  coordinate  space,  lype  and  lypeDala  determine  the  type  and  type- 
speeilic  information,  respectively. 

Deleteltem  (sdf  iiem) 

Delete  hem  from  the  currently  open  symbol  definition  in  sdf 

lnquireltem(sdf  hem)  >c\ienl.  lype.  lypeDaia 
Return  the  parameters  for  iiem  in  sdf 

InguixcCall  (sdf  hem)  >  eaUedSymbol 
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Returns  the  item  name,  calledSymbol,  of  the  symbol  called  by  the  Hem  in  sdf. 

Changeltem  (sdf,  item,  extent,  type,  typeDala) 

Change  the  parameters  of  an  already  existing  item  in  sdf.  This  is  equivalent  to  deleting  an  item 
and  tlien  reinserting  it,  so  the  item  must  be  part  of  the  open  symbol. 


4.4.2.  Vgt  Management 

Once  the  Vcis  client  has  defined  some  graphical  objects,  it  or  the  user  needs  to  provide  information  as  to 
how  die  objects  should  be  viewed.  The  Vers  lets  a  user  view  objects  in  any  Vo  r  anywhere  on  the  screen  in 
views.  Hach  view  has  a  zoom  factor,  a  window  on  the  world  coordinates  of  the  VGT,  and  screen  coordinates 
which  determine  its  viewport.  Although  the  client  can  create  default  views,  the  user  can  change  them  with  the 
view  manager,  and  create  and  destroy  more  of  them. 

I'lach  Vg  i  can  exist  in  zero  or  more  views,  but  each  view  has  exactly  one  VGT  associated  with  it.  Each  VGT 
is  asscKiatcd  with  at  most  one  Sni ,  but  each  Soi-  may  be  associated  with  several  Vgts.  Symbol  definitions  are 
shared  between  Vg  i  s,  but  instances  of  symbols  are  not. 

Routines  for  clients'  manipulation  of  Vgts  and  views  include: 

CreateVGT (type,  name,  sdf  item)  =>  vgt 

Create  a  Vg  i  of  type  type  and  return  its  identifier  in  vgt.  name  is  a  client-specified  symbolic  name 
for  die  Vg  i  Uiat  may  be  used  later  to  select  that  Vgt  for  input,  item  in  j<^is  placed  as  the  "top- 
level"  item  in  the  Vg  i  ;  it  can  be  zero  to  indicate  a  blank  Vg  t.  ITie  type  can  be  some  combination 
of  Text.  Graphics,  and  Zoomable. 

Destroy yGT (vgt.  andViews) 

Destroy  the  given  vgt.  If  andViews  is  set,  all  the  views  of  the  Vgt  will  also  be  destroyed. 

CreateView (vgt.  viewport,  wXmin.  wYmin,  zoom.  showGrid) 

Create  a  view  of  the  given  display,  with  viewport  determining  the  default  viewport.  wXmin  and 
wYmin  arc  the  world  coordinates  to  map  to  the  left  bottom  corner  of  die  viewport;  die  amount  of 
the  world  actually  viewed  depends  on  the  size  of  the  viewport  and  the  zoom  factor.  The  zoo;/i 
factor  IS  the  power  of  two  to  multiply  world  coordinates  to  get  screen  coordinates:  it  may  be 
negative,  to  denote  that  a  view  is  zoomed  out.  M  showGrid  is  set,  a  grid  of  points  is  displayed  in 
die  viewport. 


4.4.3.  Input 

A  single  synchronous  input  routine  is  provided; 

GetUvent  (cventMask,  scorch  Buttons.  scarchType)  ~  }  event  Descriptor 

Wait  for  an  input  event  to  vKCur  and  return  a  variant  record  in  event  Descriptor  ihui  describes  the 
event.  I  hc  record  should  contain  the  type  of  the  event,  and  die  relevant  typc-dcpcndcnl 
information,  event  Mask  specifics  die  acceptable  types  of  input  events:  keyboard,  button,  locator, 
pick,  or  valuator.  srarchButtons  and  scarchType  are  used  fvir  picking;  seorchType  specifics  the 
depth  of  the  sc.irch  (in  the  hierarchical  Snt )  and  the  typc(s)  of  the  objcct(s)  to  search  for. 
search  Buttons  indicates  the  set  of  buttons  (on  a  mouse,  say)  diat  must  be  pushed  in  order  for  an 
object  to  he  selected. 
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4.4.4.  Output 

I’he  only  way  to  display  a  graphical  object  in  a  Vgt  is  to  define  it  as  a  symbol  and  execute  the  following 
routine: 

Display  hem  (vgu  sdf,  lop) 

Changes  the  top-Icvcl  item  in  vgt  to  be  item  in  sdf.  The  new  item  is  displayed  in  every  view  of  the 
Vgt. 

CreateView  executes  an  implicit  D  isplay I  tern  eifter  cTezftog  the  view. 


4.4.5.  Menu  Support 

PopUp(menu)  selection 

Display  a  function  menu,  consisting  of  an  array  of  strings,  to  the  user.  When  the  user  selects  a 
particular  item,  return  the  index  in  the  array  in  selection. 

4.4.6.  Terminal  Emulation 

The  Vgip  supports  a  text  Vgt  mode  optimized  for  page-mode  terminal  emulation.  Specifically,  an 
application  may  treat  a  Vgt  as  a  standard  ANSI  terminal  (1).  Such  an  application  need  not  know  anything 
about  the  graphical  facilities  of  the  VOTP.  and  may  use  the  Ansi  terminal  protocol  to  communicate  with  the 
Vgts.  That  proUKol  is  encapsulated  within  the  Vgtp  without  the  application’s  knowledge.  Output  to  the 
Vo  r  is  stored  in  a  po(/(331.  which  is  a  symbol  within  an  Sdf. 


nil  NETWORK  GRAITIICS  PROIOCOI. 
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The  NetworkGraphics  Protocol 


The  previous  section  presented  a  high-level  object-oriented  virtual  graphics  terminal  protocol  that  attempts 
to  limit  both  the  frequency  of  communication  between  application  and  Vors  and  the  amount  of  data 
transmitted  at  any  one  time.  The  Vg  it  is  constant  over  all  clients.  However,  some  clients  have  no  knowledge 
of  the  Vg  IT  and  some  clients  are  miming  on  machines  that  do  not  support  the  interprocess  communication 
mechanisms  underlying  tlic  Vg  it.  The  following  situations  arise  (Figure  5-1): 


Figure  5-1 :  Possible  clients  of  the  Vgts. 

•  Client  A  runs  on  the  workstation  and  communicates  via  the  VciT. 

•  Client  B  runs  on  a  machine  that  supports  network-transparent  interprocess  communication.  B 
communicates  with  the  Vg  i  s  via  the  Vg  ii’,  as  in  the  case  of  a  client  A. 


•  Client  C  runs  on  a  machine  that  docs  not  support  network-transparent  interprocess 
communication,  but  docs  sup|)ort  a  traditional  network  architecture  (the  Internet  proUKol 
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family  [42],  say).  In  addition,  a  VGIT  interface  package  is  available  that  encapsulates  the  Vgtp 
within  the  appropriate  transport  proKxrol.  Similarly,  a  local  ageni  for  the  client  will  be  created  on 
die  worksuition  to  decapsulatc  tlic  Vgtp.  Thus,  the  client  may  still  be  written  in  terms  of  the 
Vo  I  P  and  neither  it  nor  the  Vgts  have  any  knowledge  that  the  other  is  remote. 

•  Client  D  has  no  knowledge  of  the  VG  IS  or  the  Vgtp;  it  wishes  to  regard  the  workstation  as  just 
another  terminal.  The  local  agent  is  "user  IT:i.NF:r"  and  performs  the  appropriate  translations 
between  rp.i.M-a  and  Vgi  p. 

•  Client  E  is  distributed  between  the  workstation  and  one  or  more  other  machines.  The  local  agent 
is  responsible  for  representing  the  muitilude  to  the  Vgts.  Jt  must  perform  the  appropriate  set  of 
protocol  conversions  indicated  above.  In  addition,  it  may  wish  to  perform  application-specific 
functions,  such  as  caching.  In  this  event,  the  protcxrol  used  to  communicate  with  the  remote 
clients  may  require  more  dian  transport  service. 

All  clients  but  A  make  use  of  a  network  transport  protocol.  Client  B  employs  an  interprocess 
communication  prouKol  that  has  nothing  to  do  with  graphics  per  sc.  Client  D  employs  a  protocol  that  in  no 
way  depends  on  knowledge  of  the  \'gis  and  typically  has  nothing  to  do  with  graphics;  in  order  to  run,  an 
appropriate  protocol-convertei  {user  ft  i  nit)  must  run  on  the  workstation. 

Clients  C  and  E.  on  the  other  hand,  know  all  about  the  Vg  i'S  and  arc  very  interested  in  graphics.  We  will 
refer  to  the  transport  protocol  they  employ  ;is  the  neiiwrk  graphics  protocol  {Uct‘).  The  Ngp  may  be  identical 
to  an  existing  tninsport  protocol,  it  may  be  a  problem-oriented  protocol  [46],  or  it  may  itself  be  a  multi-level 
protocol.  Client  C.  for  example,  may  find  Internet  r(  l>[44|  or  TlT.M'  t  [4.^]  acceptable.  Client  £.  however, 
may  wish  U)  maintain  a  repliciited  database  (the  main  database  and  the  cache),  or  may  wish  to  trade  reliability 
against  cost.  In  tliis  case,  the  Ngp  offers  considerably  more  fti.iction  than  mere  cncapsulation/dccapsulation 
of  the  Vgtp. 


5.1.  Reliability  Issues 

An  important  issue  is  tlie  appropriate  transport  protocol  required  to  support  network  graphics.  Possible 
choices  incluile  dat.igrams,  byte  streams,  and  packet  (or  message)  streams.  One  might  argue  that  streams  arc 
most  appropri.ite  bectiuse  they  generally  provide  a  high  degree  of  reliability,  they  can  be  used  with  a  wide 
diversity  of  terminals  and  networks,  and  they  ease  the  job  of  programming  both  tlic  design  aids  and  the 
virtual  graphics  tcrmm.il.  In  addition,  if  the  workstation  and  remote  host  interact  frequently  and  in  volume, 
high  bandwidth  is  required;  this  is  better  .ichicved  with  s  irtual  circuits. 

If  bandw  idth  requirements  are  low.  then  we  arc  interested  in  low  delay,  which  suggests  that  datagrams  arc 
more  appropriate.  In  addition,  graphics  d.ita  is  less  sensitive  to  data  loss  or  corruption  tlian,  for  example,  file 
dam.  If  a  line  on  a  bitm.ip  display  is  corrupted,  it  has  minimal  effect  on  tlie  picture  due  to  the  redundancy 
provided  by  Uic  other  lines,  l•urlhcrmore,  interactive  graphics  as  real-time  communication  places  greatest 
importance  on  the  most  recent  data,  often  not  caring  about  tlic  loss  of  older  data.  In  contrast,  streams  under 
load  tend  to  lose  or  delay  new  data  in  favor  of  old  data. 

The  graphical  rcpreseni.ition  also  imp.tcts  our  choice.  If  high-level  infonnation  is  being  transmitted  via 
datagrams,  the  loss  of  a  single  datagram  may  be  catastrophic.  Moreover,  since  high-level  infonnation 
ty  pically  comes  in  hursts,  packet  streams  are  more  appropriate  than  byte  streams. 

1  astly,  the  network  technology  impacts  our  decision.  In  fact,  it  may  impose  a  particular  decision.  An  X.25- 
based  subnetwork,  for  ex.imple.  dictates  virtual  circuits  (by  te  streams).  Ironically,  local  networks  frequently 
provide  simil.ii  reli.ibility  at  the  d.ita  link  level.  I'hc  most  difficult  problems  arise  with  long-haul,  datagram- 
based  networks  such  as  the  AiH’AM  I'. 

I'ortunately,  the  V  architecture  allows  us  to  experiment  with  any  of  these  proUKols  simultaneously.  Since 
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each  remote  application  must  have  an  agent  on  the  workstation,  the  application  and  the  agent  may 
communicate  with  whatever  protocol  they  desire. 


5.2.  Caching 

There  arc  many  reasons  tJiat  an  application  should  not  or  can  not  be  run  on  tiic  workstation.  It  may  not  be 
written  in  the  right  language;  it  may  require  more  physical  or  virtual  memory  than  is  available;  or  it  may 
require  floating-point  support.  It  may  be  more  cost-effective  to  run  it  on  a  remote  machine  when  that 
machine  is  much  faster  tlian  the  workstation. 

Unfortunately,  placing  the  application  on  another  machine  obviously  incurs  additional  communications 
costs.  One  powerful  way  of  reducing  these  costs  is  to  write  an  agent  for  the  application  that  maintains  a  cache 
of  the  "main"  data  base.  Once  a  cache  is  in  place,  the  traditional  problems  of  update  arise;  When  is  tlic  cache 
updated  and  how  much  of  it  is  updated  at  a  time.  For  example,  there  are  two  interesting  cases  in  circuit 
layout; 

•  When  viewing  the  entire  chip  it  is  typically  unnecessary  to  maintain  the  details  of  specific  butts, 
etc.  This  information  may  be  flushed  in  order  to  maintain  the  representation  for  the  higher-level 
structure. 

•  When  viewing  a  specific  component  it  is  unnecessary  to  maintain  the  representation  of  pieces  of 
the  chip  not  now  on  view. 

'Ihus  the  agent  would  be  constaictcd  in  such  a  way  so  as  to  manipulate  its  Soi-  to  maintain  only  the  necessary 
data.  Appropriate  points  in  tlie  figure  representation  would  contain  the  equivalent  of  invalid  pages,  leading 
to  the  equivalent  of  page  faults. 

T!  e  ideal  Vers  would  provide  most  of  this  support  without  requiring  that  a  special-purpose  agent  be 
written  for  each  application. 
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A  Vgts  Implementation 

The  services  and  protocols  discussed  above  have  been  implemented  as  part  of  the  distributed  operating 
system  V  [14, 15. 16, 17).  Logically,  V  consists  of  a  distributed  kernel  and  a  distributed  set  of  server  processes, 
riie  distributed  kernel  consists  of  tlie  collection  of  kernels  resident  on  the  participating  machines.  The 
individual  kernels  are  integrated  via  a  low-overhead  request- response  protocol  that  supports  transparent 
interprocess  communication  between  machines.  Servers  include  network  servers,  storage  servers,  command 
interpreters,  and,  of  course,  virtual  graphics  terminal  servers.**^ 

Ihe  Vurs  has  been  implemented  for  three  varieties  of  Sun  workstation,  running  the  V  kernel.  An 
implementation  is  in  progress  for  the  IRIS  terminal  [19]. 

6.1 .  Protocols 

The  current  VGTS  implements  the  Vgtp  discussed  above.  The  current  Ngp  consists  of  a  reliable  byte- 
stream  protocol,  namely,  Internet-  or  Pup-based  Tiu.Nirr  [9. 43].  The  VGTP  is  embedded  as  escape  sequences 
within  I'l-LNET.  Thus,  we  provide  for  clients  A  through  D  in  Figure  5-1. 

6.2.  Organization 

'llie  Vgts  consists  of  the  following  modules: 

master  multiplexor  Handles  all  client  requests  by  dispatching  to  the  appropriate  .cutine  in  the  other 
modules. 

terminal  emulator  Interprets  a  byte  stream  as  if  it  were  an  ANSI  st  ndard  terminal.  Printable  characters 
arc  added  to  text  objects,  and  control  and  escape  codes  are  mapped  into  the  proper 
Vgtp  operations. 

Sl)l  manipulator  Handles  requests  to  create,  destroy,  and  modify  graphical  objects  in  structured  display 
files. 

Sui  interpreter  Highest-level  redrawing  operations.  The  structured  display  files  are  visited 

recursively,  with  appropriate  clipping  for  extents  totally  outside  the  area  being 
redrawn. 

display  operations  I  )cvicc-indcpcndcnt  graphical  operations  called  by  the  Sor  interpreter. 

hit  detection  The  structured  display  file  is  visited,  but  instead  of  actually  drawing  the  primitives,  the 

positions  arc  checked  to  match  the  cursor's  position.  A  list  of  possibly  selected  objects 
(under  other  optional  constraints)  is  returned  to  the  client. 

v  iew  port  primitives  Perform  the  view-changing  operations. 


'^Wc  will  refer  to  both  the  scrv  icc  .and  the  server  as  Vt;  is  The  btler  is  the  software  nioJulc  that  provides  Ihe  former. 
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output  handler 


input  handlers 
view  manager 


llevicc-dependeni  graphics  primitives.  On  the  Sun  workstation  this  is  a  simple 
interface  to  the  RastcrOp  package  [11].  At  this  level  color  rectangles  are  drawn  as 
stipple  patterns  on  monochromatic  displays. 

I^vice-depcndcnt  modules  for  reading  the  keyboard,  tracking  the  mouse,  etc. 

rop-lcvcl  "client"  of  the  Yg  is,  which  provides  the  means  by  which  which  users  can 
create,  destroy,  and  modify  die  screen  layout  Viewports  can  be  moved  rigidly, 
stretched,  or  squeezed.  Views  can  be  zoomed  or  panned,  all  without  affecting  the 
applications  manipulating  the  prepresented  objects.  On  the  SUN  workstation  zooming 
is  by  powers  of  two,  and  all  motions  are  done  in  one  step.  On  the  iRlS  system  zooming 
and  moving  viewports  are  smooth,  continuous  operations. 


6.3.  Screen  Updating 

Vg  IS  provides  centralized  ratlier  than  distributed  control  of  screen  updating.  In  contrast  to  many  systems, 
there  is  a  fi.xed  set  of  graphical  primitives,  executed  under  the  control  of  the  VoTS.  This  is  primarily  due  to 
the  distributed  nature  of  die  envisioned  Vgis  applications.  The  concept  of  "user-defined"  objects  has  been 
investigated,  but  has  not  been  implemented  due  to  the  performance  problems  it  would  introduce. 


6.4.  Overlapping  Viewports 

Originally,  viewports  were  restricted  to  lie  entirely  on  the  screen  and  to  not  overlap.  However,  this  proved 
to  be  inadequate,  since  screen  space  quickly  filled  up.  and  viewport  manipulation  commands  often  failed. 
I  he  current  implementation  uses  a  novel  scheme  of  dividing  each  viewport  into  visible  non-overlapping 
rect.uigles  (called  subvicwporis)  whenever  the  screen  layout  changes.  I'iic  viewports  are  then  redrawn  by 
iiuer[)reting  the  structured  displ.iy  file  in  each  of  the  subviewports.  I'his  has  the  advantage  that  diere  is  no 
speed  penalty  for  updating  views  that  arc  not  obscured  (the  nomial  case).  Views  which  liave  non-rcctangular 
visible  portions  may  Uike  longer  to  update  for  complicated  Sol's,  but  almost  always  the  actual  drawing  time  is 
the  dominating  factor,  which  W  proportional  to  the  area  being  redrawn. 

The  resulting  scheme  is  clean  and  simple,  and  performs  reasonably  on  the  SUN  workstation.  One  major 
ailvantage  over  systems  that  m.iintam  obscured  bitmaps  like  the  Apollo [2 j  and  ftlit[30],  is  diat  no  extra 
memory  is  required  to  store  obscured  biuiiaps.  The  Sot'  can  represent  extremely  large  objects  in  modest 
amounts  of  memory. 


6.5.  Zooming  and  Expansion 

I  he  Vgis  provides  support  for  zooming  and  expansion  depth  that  is  invisible  to  clients.  Zooming  on  the 
Si  N  is  by  powers  of  .2.  l-,xpansiun  deptli  indicates  how  far  down  in  the  Sni-  to  go  when  displaying  a  symbol. 
If  the  evp.insion  depth  is  less  than  the  tree  height,  an  outlined  box  will  be  displayed  at  the  appropriaic  point 
in  place  of  ihe  symbol.  I  )epending  on  tiic  size  of  the  box,  the  text  name  of  die  symbol  may  also  be  displayed. 
Views  may  be  zoomed  and  expanded  independently  such  lliat  a  user  may  view  an  entire  chip  in  one  view,  for 
example,  while  simultaneously  view  ing  a  piece  of  the  chip  in  a  much  larger  view. 
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6.6.  Performance 

Current  performance  figures  are  qualitative,  based  primarily  on  experience  with  the  Yale  layout  editor. 
Yale  can  run  stand-alone  on  the  workstation,  without  V  support,  or  can  be  distributed  between  a  workstation 
and  a  VAX.  The  VAX  may  be  on  the  local  cthemet  or  anywhere  on  the  Arpanet. 

I’hc  stand-alone  version  requires  substantial  amounts  of  code  on  the  workstation  and,  as  a  result,  suffers 
from  .severe  memory  restrictions  for  data.  The  distributed  version  places  all  of  the  application-specific  code 
on  tlic  VAX,  as  well  as  the  application  model.  As  a  resulL  the  code  size  on  the  workstation  is  substantially 
reduced  and  the  restrictions  on  the  size  of  the  application  model  are  virtually  eliminated  due  to  the  address 
space  of  the  Vax  (both  physical  and  virtual). 

Response  across  an  cthernct  is  virtually  indistinguishable  from  the  stand-alone  version.  Performance 
across  the  Arpanet  is  comparable  to  that  on  the  ethernet,  although  the  variance  in  delay  is  higher.  The 
reasons  that  performance  is  comparable  include; 

1.  Fthernet-based  Vax  TlT  Nirr  delivers  on  the  order  of  14000  baud,  a  figure  easily  matched  by 
ARPANET-based  Tet.net. 

2.  Many  functions  arc  local  to  the  workstation,  including  screen  management,  panning,  and 
zooming. 

3.  1310  high-level  object-oriented  Verp  permits  small  amounts  of  data  to  be  transmitted  across  the 
network. 

More  detailed  performance  figures  arc  being  gathered. 
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Related  and  Future  Work 

Vgts  owes  a  great  deal  to  a  number  of  earlier  systems.  Sproull  and  Thomas’s  structured  format 
protocol  \S0\,  in  particular,  was  a  major  inspiration.  That  protocol  was  never  implemented,  primarily  due  to 
die  lack  of  sufficient  computing  power  in  the  available  terminals.  Moreover,  the  Vgts  supports  multiple 
applications  simultaneously. 

I'hc  Rig  Virtual  Terminal  Management  System  (Vitms).  on  the  other  hand,  was  one  of  the  earliest  systems 
to  provide  simultaneous  access  to  multiple,  possibly  distributed  applicaticns  [.^3].  The  basic  architecture  of 
the  virtual  graphics  terminal  server,  as  well  as  the  characteristics  of  a  text  pad,  arc  reminiscent  of  VlAtS,  In 
addition,  the  RlG  notion  of  grouping  virtual  terminals  ass(x:iatcd  with  a  single  application  within  a  logical 
construct  (called  a  super^indow  in  Rig)  is  an  important  feature  missing  in  Vg  IS.  When  the  user  resumes  a 
particular  activity,  all  the  virtual  terminals  would  be  brought  to  the  "top"  of  the  pile  of  viewports  (although 
they  would  continue  to  overlap  as  necessary).  An  additional  V  lAts  construct  being  considered  is  that  of  an 
screen  iinane:  images  arc  used  to  maintain  several  distinct  screen  configurations  in  the  event,  say,  diat  two 
applications  each  want  to  use  up  all  of  the  available  screen  space. 

IU>wcvcr,  ViMS  did  not  provide  graphics  support,  nor  did  it  provide  effective  terminal  emulation.  Rather, 
it  defined  a  standard  page-mode  virtual  terminal,  with  which  all  applications  were  required  to  communicate. 
In  fact,  tlic  line-  and  page-editing  features  of  the  virtual  terminal  were  so  powerful  as  to  make  it  difficult  to 
"step  down"  to  tlic  level  of  typical  page  mode  terminals.  The  Vgts  takes  a  more  cautious  approach  by 
providing  a  minimal  set  of  functions,  on  which  additional  line-,  p.igc-,  and  graphical  editing  facilities  can  be 
easily  built.  Indeed,  wc  have  built  both  a  line-editor  and  a  text-editor  with  features  similar  to  those  in  V  livts 
and  a  number  of  other  systems;  wc  are  currently  considering  moving  some  of  lliosc  functions  into  the  VGTS 
proper. 

A  number  of  sophisticated  window  systems  have  been  built  for  personal  computers,  most  of  which  evolved 
from  the  Smalltalk  environment  (52|.  These  include  Cedar  Viewers  |35]  for  die  Xerox  I)  machines, 
NWS  (39,  59|  for  the  l  isp  Machine,  and  the  Star  user  interface  |4S).  among  others.  One  shared  characteristic 
of  these  three  systems  is  that  they  are  object-oriented,  resulting  from  the  common  ancestry  of  Smalltalk  [27] 
and  Actors  [261.  The  .idv.miage  of  such  an  approach  is  extensibility,  applications  can  define  tlicir  own 
graphics  objects  and  primitives  since  screen  updating  is  effected  via  library  packages.  An  observed 
disadvantage,  at  le.ist  in  NWS  and  Star,  is  poor  performance.  In  addition,  these  systems  have  not  been  built 
with  distributed  applications  in  mind:  for  the  must  part,  applications  arc  local.  In  particular,  these  systems  do 
not  cope  well  with  existing  applic.ilions  running  on  heterogeneous  hosts  somewhere  on  an  internet.  Doing  so 
requires  ccntrali/ed  screen  updating  (at  the  workstation)  as  implemented  in  VGTS. 

The  graphical  facilities  of  the  Vtns  arc  similar  to  a  number  of  existing  graphics  packages,  including  those 
conforming  to  die  Core  [25]  and  Gks  |28|  standards.  The  principle  differences  arc: 

1.  standardized  support  for  modeling  as  well  as  viewing; 

2.  hierarchical  structure  of  ohyeets  (multilevel  \s.  segmented siructurc  [38]); 

3.  the  ability  to  handle  multiple,  distributed  applications  simultaneously. 

All  features  arc  made  possible  primarily  by  the  power  of  SUN-like  workstations. 

On  the  other  hand,  a  major  deficiency  of  the  current  implementation  is  the  lack  of  a  number  of  common 
object  types,  such  as  circles,  polygons,  splines,  and  bitmaps.  The  last  is  rather  ironic  considering  wc  currently 
support  only  raster  displays.  It  must  be  remedied  before  the  system  is  suittible  for  image  prtKCSsing  or  can 
support  multiple  character  fonts  and  character  clipping.  Wc  arc  also  working  on  31).  color,  fioating-point, 
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and  image  transformation  facilities. 

We  are  considering  how  best  to  handle  animation,  rubberbanding,  and  the  like.  For  example,  we  might 
add  the  notion  of  ephemeral  graphics  primitives  that  would  cause  changes  to  the  screen,  but  would  not  be 
stored  in  an  Sdi-.  These  would  be  similar  to  the  notion  of  temporary  segments  in  the  Core  standard.  More 
attractive  would  be  to  specify  rubberbanding,  tumbling,  and  the  like  as  an  attribute  of  the  object. 

Most  of  the  facilities  just  mentioned  represent  a  considerable  amount  of  additional  programming,  but  are 
reasonably  well-documented  in  the  literature.  More  important  from  a  research  point  of  view,  we  arc  just 
embarking  on  a  study  of  the  caching  and  reliability  issues  broached  in  Section  5.  In  addition,  we  are 
collaborating  with  the  Stanford  Intelligent  Agents  project,  among  others,  to  develop  sophisticated  user 
interfaces  built  on  top  of  the  Vci^. 

Hven  with  these  deficiencies,  the  current  VGTS  is  more  than  adequate  for  a  variety  of  applications, 
including  the  VLSI  layout  editor  that  inspired  them.  As  noted  above,  implementations  have  been  completed 
for  three  varieties  of  SUN  worksuitions  and  an  implementation  for  the  Iris  is  underway.  In  addition,  plans  arc 
underway  to  use  the  Vgts  as  the  frontend  for  Xerox  Dolphins,  Symbolics  Lisp  Machines,  and  Vax-  and  Dec- 
20-bascd  Interlisp. 
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